home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr04 / fgf_edt1.zip / BETAGUID.TXT < prev    next >
Text File  |  1993-07-01  |  17KB  |  360 lines

  1.  
  2.                      The Beta Tester's Guide
  3.  
  4.                    by Tom Rawson, JP Software
  5.  
  6.  
  7.  
  8. [Copyright 1988, 1991, 1992, JP Software Inc., All Rights
  9. Reserved.  See end of document or contact J.P. Software, 617-646-
  10. 3975, for reprint / distribution restrictions.]
  11.  
  12.  
  13. This guide is designed to give you a few ideas about what to
  14. expect and how you should behave as a "beta tester" for a piece
  15. of software.  It is written with beta testing for the small
  16. commercial or shareware developer in mind, but you may also find
  17. it useful if you're beta testing a product from a large software
  18. developer.
  19.  
  20.  
  21. What's a Beta Test?
  22.  
  23. Most programs or program enhancements of any consequence go
  24. through roughly four different phases between the original design
  25. and first release:
  26.  
  27.  
  28. (1) Design, coding, and testing by developer.
  29.  
  30.  
  31. (2) "Alpha" test by a small group selected by the developer.  In
  32. software development it's pretty easy to be so involved in the
  33. program that significant bugs or design problems are missed. 
  34. It's also almost impossible to foresee and have good judgement
  35. about all the things users might want or need, and many of these
  36. things can't be determined during the design phase.
  37.  
  38. The alpha testers are extra sets of eyes and ears for the
  39. developer.  They pick up bugs that an end user might look at and
  40. say "gee, they should never have even considered releasing this
  41. thing!"  They try out different approaches to the user interface,
  42. run the software on a variety of hardware configurations, or
  43. debate suggestions on what functions should be included or
  44. excluded.  In a large company the alpha testers may all be
  45. internal to the company, or may include only a very small number
  46. of trusted and technically competent customers.
  47.  
  48. When the alpha test is complete the product may not be bug free,
  49. but it is known to run reasonably well on a variety of systems
  50. without exhibiting major bugs or destroying other parts of the
  51. system.  It also usually has at least reasonably good agreement
  52. from the alpha test group that it meets their needs and the needs
  53. they perceive users will have.
  54.  
  55.  
  56. (3) "Beta" test by a larger and more representative group of
  57. customers, either those who expressed interest in testing a new
  58. product, or those who are already using an older version and are
  59. willing to try out a new release.  
  60.  
  61. The job these people have is to make sure the product is solid
  62. before it is released, i.e. that it runs properly on the widest
  63. possible variety of appropriate hardware; that both major and
  64. minor bugs are identified and taken care of; that auxiliary items
  65. such as support programs, documentation, and help screens are
  66. well-designed and work correctly; and that any additional design
  67. and interface problems are identified and dealt with.
  68.  
  69. Most products go through more than one phase of beta testing
  70. before release, and there are usually a number of updates
  71. supplied to beta testers as the product is refined and corrected
  72. in response to their comments.
  73.  
  74.  
  75. (4) Release of the product to the public.
  76.  
  77.  
  78. Once these four phases are complete there is often ongoing beta
  79. testing of additional enhancements to the program.  This may
  80. begin immediately after release, or be delayed for a while,
  81. depending on the development cycle the developer wants or has the
  82. resources to follow.
  83.  
  84.  
  85. Beta Testing Pros and Cons
  86.  
  87. If you decide to beta test a product you are going to get some
  88. benefits.  You will get the latest release early, usually well
  89. ahead of others; this can be especially important if you need to
  90. use some new features of a product to get your job done or your
  91. application running.  You will have an opportunity to shape the
  92. nature of the final product, which may be important if it's
  93. something you use or plan to use heavily.  And you may have a
  94. chance to learn the internal workings of the product.  You'll
  95. probably get to know the developer and support staff well, and
  96. have an inside connection for any future questions or support
  97. needs.
  98.  
  99. In most cases, you will receive a free copy of the product or
  100. update (some large companies actually pay beta testers, but it is
  101. not a common practice for PC software vendors, especially
  102. shareware developers and small companies).
  103.  
  104. You are also going to have some frustrations.  The program is
  105. going to have bugs in it.  Some of them will be in the piece that
  106. you just had to have yesterday.  The user interface will change
  107. on you and you'll have to re-learn the command-line switches, or
  108. the function keys, or some other part of the program's behavior. 
  109. Things that used to work will "break" in a new release, then get
  110. fixed again.  The developer will not be able to fix everything
  111. right away.  Some of your suggestions will be rejected for
  112. reasons you don't agree with.
  113.  
  114. Most beta testers of course find that the benefits outweigh the
  115. frustrations; if not they don't become (or remain) beta testers.
  116.  
  117.  
  118. Beta Testing Guidelines
  119.  
  120. These guidelines are intended to help you do what's necessary to
  121. make the beta test a productive experience for both you and the
  122. program's developer.  They aren't absolute of course, and some
  123. will vary from situation to situation.  Some of them may seem to
  124. conflict; that's intentional.  Striking a good balance is what
  125. will make your participation in the beta test go well.
  126.  
  127.  
  128. (1) Verify what you find.  Does the program behave strangely if
  129. you run it on Sunday morning, and work fine the rest of the time? 
  130. Don't fire off a bug report the first time, try it again.  Don't
  131. overdo it -- there's no point in beating your head against the
  132. wall -- but two or three tries at reproducing the problem and
  133. determining under exactly which conditions it occurs may be
  134. immensely helpful to the developer.  Remember, s/he isn't sitting
  135. there at your computer, and the problem may not show up the same
  136. way on another system.
  137.  
  138.  
  139. (2) Don't jump to conclusions.  If you report that "this thing
  140. doesn't work when run with my pop-up calculator", you should try
  141. to verify that that's really what's happening.  Is it really the
  142. calculator, or is it only when the calculator is loaded with the
  143. disk cache that the problem occurs?  Has your favorite
  144. hexadecimal to dodecahedral conversion algorithm really been
  145. eliminated in the new release, or was it just accidentally left
  146. off the help screen?  It is much easier to send the developer off
  147. on a wild goose chase if it appears that you've narrowed the
  148. problem down further than you actually have.  
  149.  
  150. Another way to say this is, when reporting on something to the
  151. developer, differentiate between what you know and what you're
  152. guessing at:   "With my Paradise VGA board and a Magnavox monitor
  153. the text comes out pink on red, perhaps there's a problem with
  154. the color selections on VGAs" rather than "The color selections
  155. don't work on VGAs any more".  Of course the developer must
  156. "edit" your reports in this same fashion, but the more specific
  157. you can be about what you actually know, the better.
  158.  
  159.  
  160. (3) Report everything.  Verify it first, and report only what you
  161. found, but do report it.  The thing you run across once that
  162. appears minor may be a key issue for some other type of customer,
  163. and the developer will want to know about it.  Don't make the
  164. decision for the developer that something is too small to matter.
  165.  
  166.  
  167. (4) Express your opinion, positive and negative.  Is there
  168. something you like, especially something new?  Say so!  If you
  169. don't the developer may decide it isn't such a big deal and get
  170. rid of it, when really it made the program much better.  If the
  171. new menu arrangement is really super and worth losing
  172. compatibility with the old one, the developer needs to know.
  173.  
  174. Is there something you don't like, even though it's not a bug? 
  175. Maybe the human engineering of the keyboard is great with the
  176. function keys at the left, but on a keyboard with top-row
  177. function keys it is incredibly difficult to use.  Say that too --
  178. once (then see the next section!).  Don't restrict yourself to
  179. bug reports; the developer tries to assemble a representative
  180. group of testers, and relies on you to state your opinion
  181. thoughtfully.
  182.  
  183. Be sure you provide alternatives when you have problems with the
  184. design:  "It would be better if it did Y" rather than just "It
  185. shouldn't do X".  The developer is going to have a much easier
  186. time being responsive if your suggestions are constructive. 
  187. Sometimes this is difficult -- for example, if the program is too
  188. slow, you may not know how to make it faster.  But you can at
  189. least indicate why that is a problem:  explain just which parts
  190. are too slow to meet your needs, and what those needs are.
  191.  
  192.  
  193. (5) Expect to be snubbed.  OK, maybe that's a little strong.  But
  194. remember that the developer is dealing with a lot of (usually
  195. conflicting) ideas, suggestions, and reports.  Yours is not going
  196. to be given a high priority simply because it is important to
  197. you, unless it also fits in with other plans, the reasonable way
  198. to do the programming, etc.  
  199.  
  200. Most developers are quite responsive during a beta test, but they
  201. also have to keep the product operating consistently and do their
  202. work efficiently; as a result, they may choose to make decisions
  203. you don't like.  The best developers will consider the product to
  204. be yours as much as theirs, but they must still be the ultimate
  205. architect of how it looks and works.  
  206.  
  207. Further, you may have ideas that sound good on the surface, but
  208. turn out to be infeasible because they require rewriting a major
  209. portion of the code, or would need a change to the operating
  210. system, etc.  Often these things cannot be seen from the outside,
  211. so your suggestion may appear like the "obvious" way to do
  212. things, yet still be difficult to impossible to implement.
  213.  
  214. So go ahead and argue for your point of view.  Present it, see if
  215. you can convince your fellow beta testers (if you have contact
  216. with them) and/or the developer.  But if you lose the battle, let
  217. it go -- if you can't, you probably shouldn't be beta testing the
  218. product.
  219.  
  220.  
  221. (6) Keep your files backed up.  There are all sorts of ways that
  222. a bug can cause a disk error that messes up a file, a directory,
  223. or even a whole disk.  These are usually very rare, but they
  224. cannot be entirely eliminated without testing; since you're one
  225. of the testers, you need to be prepared to handle them, and check
  226. for them.  
  227.  
  228. For example, on an MS-DOS system when testing a program that uses
  229. files (as most do), you should run CHKDSK periodically to
  230. determine that your file allocation table isn't getting mixed up. 
  231. Of course if it is, try to verify that the problem is caused by
  232. the program you're testing -- many things can mess up the disk,
  233. and it is the kind of bug you need to verify as carefully as
  234. possible before sounding an alarm, and report as specifically as
  235. possible.
  236.  
  237.  
  238. (7) Don't use a beta test version for critical applications.  In
  239. some cases you may have to, but be prepared for the consequences. 
  240. At least once during the beta test you will probably find that
  241. something you need isn't working, and you'll have to go back to
  242. an earlier version, or the previous release (pre-beta test), to
  243. get your work done.  If you have become dependent on new
  244. features, you may be in trouble.  
  245.  
  246. Similarly, features or methods of operation added during the beta
  247. test can also be removed if problems crop up, so the thing you
  248. need most may disappear.  This is rare, but sometimes the
  249. developer will find that a feature just doesn't fit with the rest
  250. of the program and has to be changed.  As long as the product
  251. hasn't been released, that's the developer's prerogative.
  252.  
  253.  
  254. (8) Use the program as you normally would.  On the one hand, the
  255. developer is expecting you to really use the program, not just
  256. try it a couple of times -- if you're just a casual user, let the
  257. developer know as they may need more regular users to make the
  258. test worthwhile.  But on the other hand, you don't need to overdo
  259. it or try every single feature, unless you want to.  
  260.  
  261. The developer has recruited beta testers with a variety of
  262. experience levels, needs, and uses of the product, to be sure all
  263. aspects are tested.  If you use the product in your usual way and
  264. pay careful attention to any problems, questions, or suggestions,
  265. you can feel comfortable that you're doing a good job.  
  266.  
  267. Do try out new features that you're interested in, or test the
  268. program at "boundary conditions" if you can.  ("What happens if I
  269. give it a *really* big file to process?  How about a really small
  270. one?"). But it is probably more valuable to the developer to have
  271. you watching carefully what happens during normal use than to
  272. have you trying all sorts of features you aren't familiar with
  273. but not really paying attention to what happens and how they
  274. work.
  275.  
  276.  
  277. (9) Keep things confidential.  In virtually all cases the
  278. developer will require that some or all aspects of the beta test
  279. be kept confidential.  Respect this agreement.  Don't pass copies
  280. of the program around, and don't talk about anything you aren't
  281. supposed to talk about.  The developer has determined what
  282. information s/he wants to make public and when based on what
  283. market the program is in and how the new product or version will
  284. be publicized; it's not up to you to decide this on your own.  Of
  285. course the developer needs to make these restrictions clear at
  286. the beginning (most developers use a formal, signed beta test or
  287. non-disclosure agreement which spells these things out exactly). 
  288. You could even be subject to legal action if you violated such an
  289. agreement.
  290.  
  291.  
  292. (10) Keep the old versions.  You will certainly need them.  The
  293. newest version is going to fix some bugs and introduce others,
  294. some of which you may find intolerable.  The best way to handle
  295. this for most people is to save the most recent public release
  296. (if you are working on an enhancement), the most recent
  297. relatively stable beta test version, and the most recent and
  298. next-most-recent beta test versions, whether they are stable for
  299. your use or not.  This allows you to test things on different
  300. versions if you can, and go back to older stable versions if
  301. necessary.
  302.  
  303.  
  304. (11) Know when to get on (and off) the beta test "bandwagon". 
  305. Some developers may not know when their product isn't ready for
  306. beta testing yet, and some beta testers may not realize what
  307. they're getting into.  You can find lots of requests for beta
  308. testers on electronic bulletin boards and on-line services. 
  309. Virtually all of them are from reputable developers with a
  310. product that is most likely more than ready to go into beta test. 
  311. But occasionally you may find that the program is just too buggy
  312. to even try, or that it doesn't meet your needs in the way you
  313. thought it would.  
  314.  
  315. When this occurs just politely inform the developer that you'd
  316. like to withdraw from the test.  Remember that what you were
  317. promised was the right to try the new version and test it; if it
  318. doesn't work the way you wanted it to you can certainly stop.  Be
  319. gracious about it, and the developer usually will also.  
  320. Similarly, if you can't continue using the product reasonably
  321. regularly and reporting the results, or meet other conditions the
  322. developer sets, you should also withdraw, because your
  323. participation won't meet the developer's needs.  
  324.  
  325. If you do choose to withdraw before you've put in the requisite
  326. amount of effort, or you haven't met all of the developer's
  327. conditions (e.g., filling out an evaluation form) don't expect a
  328. free copy of the program when it's released, as you haven't
  329. continued with your end of the deal.  But do expect the developer
  330. to be polite about it also:  people drop out of beta tests all
  331. the time, and it's the developer's responsibility to assemble a
  332. team that can handle a little attrition.
  333.  
  334.  
  335. Conclusion
  336.  
  337. You'll probably find being a beta tester rewarding and valuable;
  338. for popular products there are often many more people ready to
  339. test than needed.  If you pay attention to what you're doing and
  340. follow the guidelines above, you can make it work well for both
  341. yourself and the developer.
  342.  
  343.  
  344.  
  345.  
  346. ----------------------------------------------------------------
  347.  
  348. This guide was written by Tom Rawson, JP Software Inc.,
  349. Arlington, MA, and is Copyright 1988, 1991, 1992, JP Software
  350. Inc., All Rights Reserved.  Permission is granted for developers
  351. of public-domain and shareware software to distribute this
  352. material at no charge in conjunction with beta tests of their
  353. products, provided this notice is included.  Any other use
  354. requires specific permission from JP Software.  We can be
  355. contacted via CompuServe ID 75300,210 or by calling 617-646-3975
  356. during normal business hours.  JP Software is the publisher of
  357. 4DOS, the award-winning COMMAND.COM replacement for MS-DOS,
  358. PC_DOS, and DR-DOS, and of 4OS2, the superior replacement command
  359. processor for OS/2 1.2, 1.3, and 2.0.
  360.